Application Customization

ABSTRACT

Methods and systems for customizing applications in enterprise mobility management systems are described herein. A client agent software application on a mobile device may be customized to embed or make available enterprise server URLs, a session cookie for authentication, and various other data during the device enrollment process. The customization of the client agent may be based on the device, user, and/or enrollment session. After the device is enrolled in the enterprise system, the embedded data may be accessed by the client agent application to support seamless single-sign-on during first-time use. Additional customized applications based on device, user, and/or enrollment session, may be generated and provided to mobile devices during or after device enrollment. Customized applications may be based on application templates, such as packaged web applications or specific implementations of hosted applications.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. application Ser.No. 14/490,198, entitled “Application Customization,” filed Sep. 18,2014, which claims priority to U.S. Provisional Patent Application Ser.No. 61/988,437, filed May 5, 2014, and entitled “ApplicationCustomization,” the contents of which are incorporated by reference intheir entirety in this disclosure.

FIELD

Aspects of the disclosure relate to computer hardware and software. Inparticular, one or more aspects of the disclosure generally relate tocomputer hardware and software for generating customized applicationsfor user devices in enterprise systems.

BACKGROUND

Mobile devices, such as smart phones, personal digital assistants,tablet computers, other types of mobile computing devices, are becomingincreasingly popular. Mobile devices are used in personal and businesssettings for a variety of purposes. Users of mobile devices may wanttheir devices to be personal and interactive, and suitable both aspersonal consumer devices and as business devices, and will oftencustomize their mobile devices by installing various mobile softwareapplications suitable to their purposes.

SUMMARY

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

To overcome limitations in the prior art described above, and toovercome other limitations that will be apparent upon reading andunderstanding the present specification, aspects described herein aredirected towards generating and providing customized applications foruser devices in enterprise systems.

One or more aspects of the disclosure provide for methods, apparatuses,and computer systems directed toward receiving enrollment requests fromone or more mobile devices to enroll in an mobile device management(MDM) system, generating session cookies based on device identifiers ofthe mobile devices and based on identifiers of the MDM system, andproviding the session cookies to the mobile devices. Such sessioncookies, in accordance with various aspects of the disclosure, may beunique to mobile devices, users of the mobile devices, and/or specificenrollment sessions of the mobile device into the MDM system. Accordingto additional aspects, the session cookies may be provided to the mobiledevices by transmitting the session cookies using an MDM protocol duringthe enrollment process. Additionally or alternatively, session cookiesmay be provided to the mobile devices by embedding the session cookiesinto client agent applications which then may be built and transmittedto the respective mobile devices.

According to further aspects of the disclosure, the mobile devices mayuse the session cookies to establish communication with the MDM systemduring an enrollment session. In certain examples, a mobile device maytransmit a communication containing a session cookie to facilitate theenrollment process. After receiving the session cookie from the mobiledevice, a server in the MDM system may determine whether the sessioncookie is valid based on a retrieved expiration time associated with thesession cookie.

Further aspects of the disclosure are directed to identifying one ormore of a user, a device, or an enrollment session associated with anenrollment request received from a mobile device, determining a set ofcustomized application parameters based on the user, device, orenrollment session, generating a customized application using the set ofcustomized application parameters and an application template, and thentransmitting the customized application to the mobile device in responseto the enrollment request.

These and additional aspects will be appreciated with the benefit of thedisclosures discussed in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of aspects described herein and theadvantages thereof may be acquired by referring to the followingdescription in consideration of the accompanying drawings, in which likereference numbers indicate like features, and wherein:

FIG. 1 depicts an illustrative computer system architecture that may beused in accordance with one or more illustrative aspects describedherein.

FIG. 2 depicts an illustrative remote-access system architecture thatmay be used in accordance with one or more illustrative aspectsdescribed herein.

FIG. 3 depicts an illustrative enterprise mobility management system.

FIG. 4 depicts another illustrative enterprise mobility managementsystem.

FIG. 5 depicts another illustrative enterprise mobility managementsystem.

FIG. 6 is a diagram showing an example process of enrolling a userdevice into an enterprise system, in accordance with one or moreillustrative aspects described herein.

FIG. 7 is a diagram showing an example process of providing MDMconfiguration data to a user device in response to an initial launch ofa client agent application after enrollment of the device, in accordancewith one or more illustrative aspects described herein.

FIG. 8 is a diagram showing an example workflow process at a user devicein response to an initial launch of a client agent application afterenrollment of the device, in accordance with one or more illustrativeaspects described herein.

FIG. 9 is a diagram showing an example process building a customizedmobile application bundle based on a mobile template application, inaccordance with one or more illustrative aspects described herein.

FIG. 10 is a diagram showing an example process of modifying andconfiguring a template application to create a new customizedapplication, in accordance with one or more illustrative aspectsdescribed herein.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings identified above and which form a parthereof, and in which is shown by way of illustration various embodimentsin which aspects described herein may be practiced. It is to beunderstood that other embodiments may be utilized and structural andfunctional modifications may be made without departing from the scopedescribed herein. Various aspects are capable of other embodiments andof being practiced or being carried out in various different ways.

As a general introduction to the subject matter described in more detailbelow, aspects described herein are directed towards customizingapplications in enterprise mobility management systems. Varioussituations and use cases are described in which enterprise applicationsmay be customized for users within an enterprise system, and varioustechniques and examples are described for customizing such applications.In some cases, a client agent software application on a mobile devicemay be customized during the device enrollment process to embed or makeavailable enterprise server URLs, a session cookie for authentication,and various other data. The customization of the client agent may bebased on the device, user, and/or enrollment session. After the deviceis enrolled in the enterprise system, the embedded data may be accessedby the client agent application to support seamless single-sign-onduring first-time use. Additional customized applications based ondevice, user, and/or enrollment session, may be generated and providedto mobile devices during or after device enrollment. Customizedapplications may be based on application templates, such as packaged webapplications or specific implementations of hosted applications.

It is to be understood that the phraseology and terminology used hereinare for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof. The use of the terms “mounted,” “connected,”“coupled,” “positioned,” “engaged” and similar terms, is meant toinclude both direct and indirect mounting, connecting, coupling,positioning and engaging.

Computing Architecture

Computer software, hardware, and networks may be utilized in a varietyof different system environments, including standalone, networked,remote-access (aka, remote desktop), virtualized, and/or cloud-basedenvironments, among others. FIG. 1 illustrates one example of a systemarchitecture and data processing device that may be used to implementone or more illustrative aspects described herein in a standalone and/ornetworked environment. Various network nodes 103, 105, 107, and 109 maybe interconnected via a wide area network (WAN) 101, such as theInternet. Other networks may also or alternatively be used, includingprivate intranets, corporate networks, LANs, metropolitan area networks(MAN) wireless networks, personal networks (PAN), and the like. Network101 is for illustration purposes and may be replaced with fewer oradditional computer networks. A local area network (LAN) may have one ormore of any known LAN topology and may use one or more of a variety ofdifferent protocols, such as Ethernet. Devices 103, 105, 107, 109 andother devices (not shown) may be connected to one or more of thenetworks via twisted pair wires, coaxial cable, fiber optics, radiowaves or other communication media.

The term “network” as used herein and depicted in the drawings refersnot only to systems in which remote storage devices are coupled togethervia one or more communication paths, but also to stand-alone devicesthat may be coupled, from time to time, to such systems that havestorage capability. Consequently, the term “network” includes not only a“physical network” but also a “content network,” which is comprised ofthe data—attributable to a single entity—which resides across allphysical networks.

The components may include data server 103, web server 105, and clientcomputers 107, 109. Data server 103 provides overall access, control andadministration of databases and control software for performing one ormore illustrative aspects describe herein. Data server 103 may beconnected to web server 105 through which users interact with and obtaindata as requested. Alternatively, data server 103 may act as a webserver itself and be directly connected to the Internet. Data server 103may be connected to web server 105 through the network 101 (e.g., theInternet), via direct or indirect connection, or via some other network.Users may interact with the data server 103 using remote computers 107,109, e.g., using a web browser to connect to the data server 103 via oneor more externally exposed web sites hosted by web server 105. Clientcomputers 107, 109 may be used in concert with data server 103 to accessdata stored therein, or may be used for other purposes. For example,from client device 107 a user may access web server 105 using anInternet browser, as is known in the art, or by executing a softwareapplication that communicates with web server 105 and/or data server 103over a computer network (such as the Internet).

Servers and applications may be combined on the same physical machines,and retain separate virtual or logical addresses, or may reside onseparate physical machines. FIG. 1 illustrates just one example of anetwork architecture that may be used, and those of skill in the artwill appreciate that the specific network architecture and dataprocessing devices used may vary, and are secondary to the functionalitythat they provide, as further described herein. For example, servicesprovided by web server 105 and data server 103 may be combined on asingle server.

Each component 103, 105, 107, 109 may be any type of known computer,server, or data processing device. Data server 103, e.g., may include aprocessor 111 controlling overall operation of the rate server 103. Dataserver 103 may further include random access memory (RAM) 113, read onlymemory (ROM) 115, network interface 117, input/output interfaces 119(e.g., keyboard, mouse, display, printer, etc.), and memory 121.Input/output (I/O) 119 may include a variety of interface units anddrives for reading, writing, displaying, and/or printing data or files.Memory 121 may further store operating system software 123 forcontrolling overall operation of the data processing device 103, controllogic 125 for instructing data server 103 to perform aspects describedherein, and other application software 127 providing secondary, support,and/or other functionality which may or might not be used in conjunctionwith aspects described herein. The control logic may also be referred toherein as the data server software 125. Functionality of the data serversoftware may refer to operations or decisions made automatically basedon rules coded into the control logic, made manually by a user providinginput into the system, and/or a combination of automatic processingbased on user input (e.g., queries, data updates, etc.).

Memory 121 may also store data used in performance of one or moreaspects described herein, including a first database 129 and a seconddatabase 131. In some embodiments, the first database may include thesecond database (e.g., as a separate table, report, etc.). That is, theinformation can be stored in a single database, or separated intodifferent logical, virtual, or physical databases, depending on systemdesign. Devices 105, 107, 109 may have similar or different architectureas described with respect to device 103. Those of skill in the art willappreciate that the functionality of data processing device 103 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc.

One or more aspects may be embodied in computer-usable or readable dataand/or computer-executable instructions, such as in one or more programmodules, executed by one or more computers or other devices as describedherein. Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types when executed by a processor ina computer or other device. The modules may be written in a source codeprogramming language that is subsequently compiled for execution, or maybe written in a scripting language such as (but not limited to)HyperText Markup Language (HTML) or Extensible Markup Language (XML).The computer executable instructions may be stored on a computerreadable medium such as a nonvolatile storage device. Any suitablecomputer readable storage media may be utilized, including hard disks,CD-ROMs, optical storage devices, magnetic storage devices, and/or anycombination thereof. In addition, various transmission (non-storage)media representing data or events as described herein may be transferredbetween a source and a destination in the form of electromagnetic wavestraveling through signal-conducting media such as metal wires, opticalfibers, and/or wireless transmission media (e.g., air and/or space).Various aspects described herein may be embodied as a method, a dataprocessing system, or a computer program product. Therefore, variousfunctionalities may be embodied in whole or in part in software,firmware and/or hardware or hardware equivalents such as integratedcircuits, field programmable gate arrays (FPGA), and the like.Particular data structures may be used to more effectively implement oneor more aspects described herein, and such data structures arecontemplated within the scope of computer executable instructions andcomputer-usable data described herein

With further reference to FIG. 2, one or more aspects described hereinmay be implemented in a remote-access environment. FIG. 2 depicts anexample system architecture including a generic computing device 201 inan illustrative computing environment 200 that may be used according toone or more illustrative aspects described herein. Generic computingdevice 201 may be used as a server 206 a in a single-server ormulti-server desktop virtualization system (e.g., a remote access orcloud system) configured to provide virtual machines for client accessdevices. The generic computing device 201 may have a processor 203 forcontrolling overall operation of the server and its associatedcomponents, including RAM 205, ROM 207, I/O module 209, and memory 215.

I/O module 209 may include a mouse, keypad, touch screen, scanner,optical reader, and/or stylus (or other input device(s)) through which auser of generic computing device 201 may provide input, and may alsoinclude one or more of a speaker for providing audio output and a videodisplay device for providing textual, audiovisual, and/or graphicaloutput. Software may be stored within memory 215 and/or other storage toprovide instructions to processor 203 for configuring generic computingdevice 201 into a special purpose computing device in order to performvarious functions as described herein. For example, memory 215 may storesoftware used by the computing device 201, such as an operating system217, application programs 219, and an associated database 221.

Computing device 201 may operate in a networked environment supportingconnections to one or more remote computers, such as terminals 240 (alsoreferred to as client devices). The terminals 240 may be personalcomputers, mobile devices, laptop computers, tablets, or servers thatinclude many or all of the elements described above with respect to thegeneric computing device 103 or 201. The network connections depicted inFIG. 2 include a local area network (LAN) 225 and a wide area network(WAN) 229, but may also include other networks. When used in a LANnetworking environment, computing device 201 may be connected to the LAN225 through a network interface or adapter 223. When used in a WANnetworking environment, computing device 201 may include a modem 227 orother wide area network interface for establishing communications overthe WAN 229, such as computer network 230 (e.g., the Internet). It willbe appreciated that the network connections shown are illustrative andother means of establishing a communications link between the computersmay be used. Computing device 201 and/or terminals 240 may also bemobile terminals (e.g., mobile phones, smartphones, personal digitalassistants (PDAs), notebooks, etc.) including various other components,such as a battery, speaker, and antennas (not shown).

Aspects described herein may also be operational with numerous othergeneral purpose or special purpose computing system environments orconfigurations. Examples of other computing systems, environments,and/or configurations that may be suitable for use with aspectsdescribed herein include, but are not limited to, personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network personal computers (PCs), minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices, and the like.

As shown in FIG. 2, one or more client devices 240 may be incommunication with one or more servers 206 a-206 n (generally referredto herein as “server(s) 206”). In one embodiment, the computingenvironment 200 may include a network appliance installed between theserver(s) 206 and client machine(s) 240. The network appliance maymanage client/server connections, and in some cases can load balanceclient connections amongst a plurality of backend servers 206.

The client machine(s) 240 may in some embodiments be referred to as asingle client machine 240 or a single group of client machines 240,while server(s) 206 may be referred to as a single server 206 or asingle group of servers 206. In one embodiment a single client machine240 communicates with more than one server 206, while in anotherembodiment a single server 206 communicates with more than one clientmachine 240. In yet another embodiment, a single client machine 240communicates with a single server 206.

A client machine 240 can, in some embodiments, be referenced by any oneof the following non-exhaustive terms: client machine(s); client(s);client computer(s); client device(s); client computing device(s); localmachine; remote machine; client node(s); endpoint(s); or endpointnode(s). The server 206, in some embodiments, may be referenced by anyone of the following non-exhaustive terms: server(s), local machine;remote machine; server farm(s), or host computing device(s).

In one embodiment, the client machine 240 may be a virtual machine. Thevirtual machine may be any virtual machine, while in some embodimentsthe virtual machine may be any virtual machine managed by a Type 1 orType 2 hypervisor, for example, a hypervisor developed by CitrixSystems, IBM, VMware, or any other hypervisor. In some aspects, thevirtual machine may be managed by a hypervisor, while in aspects thevirtual machine may be managed by a hypervisor executing on a server 206or a hypervisor executing on a client 240.

Some embodiments include a client device 240 that displays applicationoutput generated by an application remotely executing on a server 206 orother remotely located machine. In these embodiments, the client device240 may execute a virtual machine receiver program or application todisplay the output in an application window, a browser, or other outputwindow. In one example, the application is a desktop, while in otherexamples the application is an application that generates or presents adesktop. A desktop may include a graphical shell providing a userinterface for an instance of an operating system in which local and/orremote applications can be integrated. Applications, as used herein, areprograms that execute after an instance of an operating system (and,optionally, also the desktop) has been loaded.

The server 206, in some embodiments, uses a remote presentation protocolor other program to send data to a thin-client or remote-displayapplication executing on the client to present display output generatedby an application executing on the server 206. The thin-client orremote-display protocol can be any one of the following non-exhaustivelist of protocols: the Independent Computing Architecture (ICA) protocoldeveloped by Citrix Systems, Inc. of Ft. Lauderdale, Fla.; or the RemoteDesktop Protocol (RDP) manufactured by the Microsoft Corporation ofRedmond, Wash.

A remote computing environment may include more than one server 206a-206 n such that the servers 206 a-206 n are logically grouped togetherinto a server farm 206, for example, in a cloud computing environment.The server farm 206 may include servers 206 that are geographicallydispersed while and logically grouped together, or servers 206 that arelocated proximate to each other while logically grouped together.Geographically dispersed servers 206 a-206 n within a server farm 206can, in some embodiments, communicate using a WAN (wide), MAN(metropolitan), or LAN (local), where different geographic regions canbe characterized as: different continents; different regions of acontinent; different countries; different states; different cities;different campuses; different rooms; or any combination of the precedinggeographical locations. In some embodiments the server farm 206 may beadministered as a single entity, while in other embodiments the serverfarm 206 can include multiple server farms.

In some embodiments, a server farm may include servers 206 that executea substantially similar type of operating system platform (e.g.,WINDOWS, UNIX, LINUX, iOS, ANDROID, SYMBIAN, etc.) In other embodiments,server farm 206 may include a first group of one or more servers thatexecute a first type of operating system platform, and a second group ofone or more servers that execute a second type of operating systemplatform.

Server 206 may be configured as any type of server, as needed, e.g., afile server, an application server, a web server, a proxy server, anappliance, a network appliance, a gateway, an application gateway, agateway server, a virtualization server, a deployment server, a SecureSockets Layer (SSL) VPN server, a firewall, a web server, an applicationserver or as a master application server, a server executing an activedirectory, or a server executing an application acceleration programthat provides firewall functionality, application functionality, or loadbalancing functionality. Other server types may also be used.

Some embodiments include a first server 106 a that receives requestsfrom a client machine 240, forwards the request to a second server 106a, and responds to the request generated by the client machine 240 witha response from the second server 106 a. First server 106 a may acquirean enumeration of applications available to the client machine 240 andwell as address information associated with an application server 206hosting an application identified within the enumeration ofapplications. First server 106 a can then present a response to theclient's request using a web interface, and communicate directly withthe client 240 to provide the client 240 with access to an identifiedapplication. One or more clients 240 and/or one or more servers 206 maytransmit data over network 230, e.g., network 101.

FIG. 2 shows a high-level architecture of an illustrative desktopvirtualization system. As shown, the desktop virtualization system maybe single-server or multi-server system, or cloud system, including atleast one virtualization server 206 configured to provide virtualdesktops and/or virtual applications to one or more client accessdevices 240. As used herein, a desktop refers to a graphical environmentor space in which one or more applications may be hosted and/orexecuted. A desktop may include a graphical shell providing a userinterface for an instance of an operating system in which local and/orremote applications can be integrated. Applications may include programsthat execute after an instance of an operating system (and, optionally,also the desktop) has been loaded. Each instance of the operating systemmay be physical (e.g., one operating system per device) or virtual(e.g., many instances of an OS running on a single device). Eachapplication may be executed on a local device, or executed on a remotelylocated device (e.g., remoted).

Enterprise Mobility Management Architecture

FIG. 3 represents an enterprise mobility technical architecture 300 foruse in a BYOD environment. The architecture enables a user of a mobiledevice 302 to both access enterprise or personal resources from a mobiledevice 302 and use the mobile device 302 for personal use. The user mayaccess such enterprise resources 304 or enterprise services 308 using amobile device 302 that is purchased by the user or a mobile device 302that is provided by the enterprise to the user. The user may utilize themobile device 302 for business use only or for business and personaluse. The mobile device may run an iOS operating system, Windowsoperating system, and Android operating system, or the like. Theenterprise may choose to implement policies to manage the mobile device302. The policies may be implanted through a firewall or gateway in sucha way that the mobile device may be identified, secured or securityverified, and provided selective or full access to the enterpriseresources. The policies may be mobile device management policies, mobileapplication management policies, mobile data management policies, orsome combination of mobile device, application, and data managementpolicies. A mobile device 302 that is managed through the application ofmobile device management policies may be referred to as an enrolleddevice.

In some embodiments, the operating system of the mobile device may beseparated into a managed partition 310 and an unmanaged partition 312.The managed partition 310 may have policies applied to it to secure theapplications running on and data stored in the managed partition. Theapplications running on the managed partition may be secureapplications. In other embodiments, all applications may execute inaccordance with a set of one or more policy files received separate fromthe application, and which define one or more security parameters,features, resource restrictions, and/or other access controls that areenforced by the mobile device management system when that application isexecuting on the device. By operating in accordance with theirrespective policy file(s), each application may be allowed or restrictedfrom communications with one or more other applications and/orresources, thereby creating a virtual partition. Thus, as used herein, apartition may refer to a physically partitioned portion of memory(physical partition), a logically partitioned portion of memory (logicalpartition), and/or a virtual partition created as a result ofenforcement of one or more policies and/or policy files across multipleapps as described herein (virtual partition). Stated differently, byenforcing policies on managed apps, those apps may be restricted to onlybe able to communicate with other managed apps and trusted enterpriseresources, thereby creating a virtual partition that is impenetrable byunmanaged apps and devices.

The secure applications may be email applications, web browsingapplications, software-as-a-service (SaaS) access applications, WindowsApplication access applications, and the like. The secure applicationsmay be secure native applications 314, secure remote applications 322executed by a secure application launcher 318, virtualizationapplications 326 executed by a secure application launcher 318, and thelike. The secure native applications 314 may be wrapped by a secureapplication wrapper 320. The secure application wrapper 320 may includeintegrated policies that are executed on the mobile device 302 when thesecure native application is executed on the device. The secureapplication wrapper 320 may include meta-data that points the securenative application 314 running on the mobile device 302 to the resourceshosted at the enterprise that the secure native application 314 mayrequire to complete the task requested upon execution of the securenative application 314. The secure remote applications 322 executed by asecure application launcher 318 may be executed within the secureapplication launcher application 318. The virtualization applications326 executed by a secure application launcher 318 may utilize resourceson the mobile device 302, at the enterprise resources 304, and the like.The resources used on the mobile device 302 by the virtualizationapplications 326 executed by a secure application launcher 318 mayinclude user interaction resources, processing resources, and the like.The user interaction resources may be used to collect and transmitkeyboard input, mouse input, camera input, tactile input, audio input,visual input, gesture input, and the like. The processing resources maybe used to present a user interface, process data received from theenterprise resources 304, and the like. The resources used at theenterprise resources 304 by the virtualization applications 326 executedby a secure application launcher 318 may include user interfacegeneration resources, processing resources, and the like. The userinterface generation resources may be used to assemble a user interface,modify a user interface, refresh a user interface, and the like. Theprocessing resources may be used to create information, readinformation, update information, delete information, and the like. Forexample, the virtualization application may record user interactionsassociated with a graphical user interface (GUI) and communicate them toa server application where the server application will use the userinteraction data as an input to the application operating on the server.In this arrangement, an enterprise may elect to maintain the applicationon the server side as well as data, files, etc. associated with theapplication. While an enterprise may elect to “mobilize” someapplications in accordance with the principles herein by securing themfor deployment on the mobile device, this arrangement may also beelected for certain applications. For example, while some applicationsmay be secured for use on the mobile device, others might not beprepared or appropriate for deployment on the mobile device so theenterprise may elect to provide the mobile user access to the unpreparedapplications through virtualization techniques. As another example, theenterprise may have large complex applications with large and complexdata sets (e.g., material resource planning applications) where it wouldbe very difficult, or otherwise undesirable, to customize theapplication for the mobile device so the enterprise may elect to provideaccess to the application through virtualization techniques. As yetanother example, the enterprise may have an application that maintainshighly secured data (e.g., human resources data, customer data,engineering data) that may be deemed by the enterprise as too sensitivefor even the secured mobile environment so the enterprise may elect touse virtualization techniques to permit mobile access to suchapplications and data. An enterprise may elect to provide both fullysecured and fully functional applications on the mobile device as wellas a virtualization application to allow access to applications that aredeemed more properly operated on the server side. In an embodiment, thevirtualization application may store some data, files, etc. on themobile phone in one of the secure storage locations. An enterprise, forexample, may elect to allow certain information to be stored on thephone while not permitting other information.

In connection with the virtualization application, as described herein,the mobile device may have a virtualization application that is designedto present GUIs and then record user interactions with the GUI. Theapplication may communicate the user interactions to the server side tobe used by the server side application as user interactions with theapplication. In response, the application on the server side maytransmit back to the mobile device a new GUI. For example, the new GUImay be a static page, a dynamic page, an animation, or the like, therebyproviding access to remotely located resources.

The secure applications may access data stored in a secure datacontainer 328 in the managed partition 310 of the mobile device. Thedata secured in the secure data container may be accessed by the securewrapped applications 314, applications executed by a secure applicationlauncher 322, virtualization applications 326 executed by a secureapplication launcher 322, and the like. The data stored in the securedata container 328 may include files, databases, and the like. The datastored in the secure data container 328 may include data restricted to aspecific secure application 330, shared among secure applications 332,and the like. Data restricted to a secure application may include securegeneral data 334 and highly secure data 338. Secure general data may usea strong form of encryption such as Advanced Encryption Standard (AES)128-bit encryption or the like, while highly secure data 338 may use avery strong form of encryption such as AES 256-bit encryption. Datastored in the secure data container 328 may be deleted from the deviceupon receipt of a command from the device manager 324. The secureapplications may have a dual-mode option 340. The dual mode option 340may present the user with an option to operate the secured applicationin an unsecured or unmanaged mode. In an unsecured or unmanaged mode,the secure applications may access data stored in an unsecured datacontainer 342 on the unmanaged partition 312 of the mobile device 302.The data stored in an unsecured data container may be personal data 344.The data stored in an unsecured data container 342 may also be accessedby unsecured applications 348 that are running on the unmanagedpartition 312 of the mobile device 302. The data stored in an unsecureddata container 342 may remain on the mobile device 302 when the datastored in the secure data container 328 is deleted from the mobiledevice 302. An enterprise may want to delete from the mobile deviceselected or all data, files, and/or applications owned, licensed orcontrolled by the enterprise (enterprise data) while leaving orotherwise preserving personal data, files, and/or applications owned,licensed or controlled by the user (personal data). This operation maybe referred to as a selective wipe. With the enterprise and personaldata arranged in accordance to the aspects described herein, anenterprise may perform a selective wipe.

The mobile device may connect to enterprise resources 304 and enterpriseservices 308 at an enterprise, to the public Internet 348, and the like.The mobile device may connect to enterprise resources 304 and enterpriseservices 308 through virtual private network connections. The virtualprivate network connections, also referred to as microVPN orapplication-specific VPN, may be specific to particular applications350, particular devices, particular secured areas on the mobile device,and the like 352. For example, each of the wrapped applications in thesecured area of the phone may access enterprise resources through anapplication specific VPN such that access to the VPN would be grantedbased on attributes associated with the application, possibly inconjunction with user or device attribute information. The virtualprivate network connections may carry Microsoft Exchange traffic,Microsoft Active Directory traffic, HyperText Transfer Protocol (HTTP)traffic, HyperText Transfer Protocol Secure (HTTPS) traffic, applicationmanagement traffic, and the like. The virtual private networkconnections may support and enable single-sign-on authenticationprocesses 354. The single-sign-on processes may allow a user to providea single set of authentication credentials, which are then verified byan authentication service 358. The authentication service 358 may thengrant to the user access to multiple enterprise resources 304, withoutrequiring the user to provide authentication credentials to eachindividual enterprise resource 304.

The virtual private network connections may be established and managedby an access gateway 360. The access gateway 360 may include performanceenhancement features that manage, accelerate, and improve the deliveryof enterprise resources 304 to the mobile device 302. The access gatewaymay also re-route traffic from the mobile device 302 to the publicInternet 348, enabling the mobile device 302 to access publiclyavailable and unsecured applications that run on the public Internet348. The mobile device may connect to the access gateway via a transportnetwork 362. The transport network 362 may be a wired network, wirelessnetwork, cloud network, local area network, metropolitan area network,wide area network, public network, private network, and the like.

The enterprise resources 304 may include email servers, file sharingservers, SaaS applications, Web application servers, Windows applicationservers, and the like. Email servers may include Exchange servers, LotusNotes servers, and the like. File sharing servers may include ShareFileservers, and the like. SaaS applications may include Salesforce, and thelike. Windows application servers may include any application serverthat is built to provide applications that are intended to run on alocal Windows operating system, and the like. The enterprise resources304 may be premise-based resources, cloud based resources, and the like.The enterprise resources 304 may be accessed by the mobile device 302directly or through the access gateway 360. The enterprise resources 304may be accessed by the mobile device 302 via a transport network 362.The transport network 362 may be a wired network, wireless network,cloud network, local area network, metropolitan area network, wide areanetwork, public network, private network, and the like.

The enterprise services 308 may include authentication services 358,threat detection services 364, device manager services 324, file sharingservices 368, policy manager services 370, social integration services372, application controller services 374, and the like. Authenticationservices 358 may include user authentication services, deviceauthentication services, application authentication services, dataauthentication services and the like. Authentication services 358 mayuse certificates. The certificates may be stored on the mobile device302, by the enterprise resources 304, and the like. The certificatesstored on the mobile device 302 may be stored in an encrypted locationon the mobile device, the certificate may be temporarily stored on themobile device 302 for use at the time of authentication, and the like.Threat detection services 364 may include intrusion detection services,unauthorized access attempt detection services, and the like.Unauthorized access attempt detection services may include unauthorizedattempts to access devices, applications, data, and the like. Devicemanagement services 324 may include configuration, provisioning,security, support, monitoring, reporting, and decommissioning services.File sharing services 368 may include file management services, filestorage services, file collaboration services, and the like. Policymanager services 370 may include device policy manager services,application policy manager services, data policy manager services, andthe like. Social integration services 372 may include contactintegration services, collaboration services, integration with socialnetworks such as Facebook, Twitter, and LinkedIn, and the like.Application controller services 374 may include management services,provisioning services, deployment services, assignment services,revocation services, wrapping services, and the like.

The enterprise mobility technical architecture 300 may include anapplication store 378. The application store 378 may include unwrappedapplications 380, pre-wrapped applications 382, and the like.Applications may be populated in the application store 378 from theapplication controller 374. The application store 378 may be accessed bythe mobile device 302 through the access gateway 360, through the publicInternet 348, or the like. The application store may be provided with anintuitive and easy to use user interface.

A software development kit 384 may provide a user the capability tosecure applications selected by the user by wrapping the application asdescribed previously in this description. An application that has beenwrapped using the software development kit 384 may then be madeavailable to the mobile device 302 by populating it in the applicationstore 378 using the application controller 374.

The enterprise mobility technical architecture 300 may include amanagement and analytics capability. The management and analyticscapability may provide information related to how resources are used,how often resources are used, and the like. Resources may includedevices, applications, data, and the like. How resources are used mayinclude which devices download which applications, which applicationsaccess which data, and the like. How often resources are used mayinclude how often an application has been downloaded, how many times aspecific set of data has been accessed by an application, and the like.

FIG. 4 is another illustrative enterprise mobility management system400. Some of the components of the mobility management system 300described above with reference to FIG. 3 have been omitted for the sakeof simplicity. The architecture of the system 400 depicted in FIG. 4 issimilar in many respects to the architecture of the system 300 describedabove with reference to FIG. 3 and may include additional features notmentioned above.

In this case, the left hand side represents an enrolled/managed mobiledevice 402 with a client agent 404, which interacts with gateway server406 (which includes Access Gateway and application controllerfunctionality) to access various enterprise resources 408 and services409 such as Exchange, Sharepoint, public-key infrastructure (PKI)Resources, Kerberos Resources, and Certificate Issuance service, asshown on the right hand side above. Although not specifically shown, themobile device 402 may also interact with an enterprise application store(StoreFront) for the selection and downloading of applications.

The client agent 404 acts as the UI (user interface) intermediary forWindows apps/desktops hosted in an Enterprise data center, which areaccessed using the High-Definition User Experience (HDX)/ICA displayremoting protocol. The client agent 404 also supports the installationand management of native applications on the mobile device 402, such asnative iOS or Android applications. For example, the managedapplications 410 (mail, browser, wrapped application) shown in thefigure above are all native applications that execute locally on thedevice. Client agent 404 and the application management framework (AMF)of this architecture act to provide policy driven managementcapabilities and features such as connectivity and SSO (single sign on)to enterprise resources/services 408. The client agent 404 handlesprimary user authentication to the enterprise, normally to the AccessGateway (AG) with SSO to other gateway server components. The clientagent 404 obtains policies from gateway server 406 to control thebehavior of the managed applications 410 on the mobile device 402.

The Secure interprocess communication (IPC) links 412 between the nativeapplications 410 and client agent 404 represent a management channel,which allows client agent to supply policies to be enforced by theapplication management framework 414 “wrapping” each application. TheIPC channel 412 also allows client agent 404 to supply credential andauthentication information that enables connectivity and SSO toenterprise resources 408. Finally the IPC channel 412 allows theapplication management framework 414 to invoke user interface functionsimplemented by client agent 404, such as online and offlineauthentication.

Communications between the client agent 404 and gateway server 406 areessentially an extension of the management channel from the applicationmanagement framework 414 wrapping each native managed application 410.The application management framework 414 requests policy informationfrom client agent 404, which in turn requests it from gateway server406. The application management framework 414 requests authentication,and client agent 404 logs into the gateway services part of gatewayserver 406 (also known as NetScaler Access Gateway). Client agent 404may also call supporting services on gateway server 406, which mayproduce input material to derive encryption keys for the local datavaults 416, or provide client certificates which may enable directauthentication to PKI protected resources, as more fully explainedbelow.

In more detail, the application management framework 414 “wraps” eachmanaged application 410. This may be incorporated via an explicit buildstep, or via a post-build processing step. The application managementframework 414 may “pair” with client agent 404 on first launch of anapplication 410 to initialize the secure IPC channel and obtain thepolicy for that application. The application management framework 414may enforce relevant portions of the policy that apply locally, such asthe client agent login dependencies and some of the containment policiesthat restrict how local OS services may be used, or how they mayinteract with the application 410.

The application management framework 414 may use services provided byclient agent 404 over the Secure IPC channel 412 to facilitateauthentication and internal network access. Key management for theprivate and shared data vaults 416 (containers) may be also managed byappropriate interactions between the managed applications 410 and clientagent 404. Vaults 416 may be available only after online authentication,or may be made available after offline authentication if allowed bypolicy. First use of vaults 416 may require online authentication, andoffline access may be limited to at most the policy refresh periodbefore online authentication is again required.

Network access to internal resources may occur directly from individualmanaged applications 410 through the Access Gateway 406. The applicationmanagement framework 414 is responsible for orchestrating the networkaccess on behalf of each application 410. Client agent 404 mayfacilitate these network connections by providing suitable time limitedsecondary credentials obtained following online authentication. Multiplemodes of network connection may be used, such as reverse web proxyconnections and end-to-end VPN-style tunnels 418.

The Mail and Browser managed applications 410 have special status andmay make use of facilities that might not be generally available toarbitrary wrapped applications. For example, the Mail application mayuse a special background network access mechanism that allows it toaccess Exchange over an extended period of time without requiring a fullAG logon. The Browser application may use multiple private data vaultsto segregate different kinds of data.

This architecture supports the incorporation of various other securityfeatures. For example, gateway server 406 (including its gatewayservices) in some cases will not need to validate active directory (AD)passwords. It can be left to the discretion of an enterprise whether anAD password is used as an authentication factor for some users in somesituations. Different authentication methods may be used if a user isonline or offline (i.e., connected or not connected to a network).

Step up authentication is a feature wherein gateway server 406 mayidentify managed native applications 410 that are allowed to have accessto highly classified data requiring strong authentication, and ensurethat access to these applications is only permitted after performingappropriate authentication, even if this means a re-authentication isrequired by the user after a prior weaker level of login.

Another security feature of this solution is the encryption of the datavaults 416 (containers) on the mobile device 402. The vaults 416 may beencrypted so that all on-device data including files, databases, andconfigurations are protected. For on-line vaults, the keys may be storedon the server (gateway server 406), and for off-line vaults, a localcopy of the keys may be protected by a user password or biometricvalidation. When data is stored locally on the device 402 in the securecontainer 416, it is preferred that a minimum of AES 256 encryptionalgorithm be utilized.

Other secure container features may also be implemented. For example, alogging feature may be included, wherein all security events happeninginside an application 410 are logged and reported to the backend. Datawiping may be supported, such as if the application 410 detectstampering, associated encryption keys may be written over with randomdata, leaving no hint on the file system that user data was destroyed.Screenshot protection is another feature, where an application mayprevent any data from being stored in screenshots. For example, the keywindow's hidden property may be set to YES. This may cause whatevercontent is currently displayed on the screen to be hidden, resulting ina blank screenshot where any content would normally reside.

Local data transfer may be prevented, such as by preventing any datafrom being locally transferred outside the application container, e.g.,by copying it or sending it to an external application. A keyboard cachefeature may operate to disable the autocorrect functionality forsensitive text fields. SSL certificate validation may be operable so theapplication specifically validates the server SSL certificate instead ofit being stored in the keychain. An encryption key generation featuremay be used such that the key used to encrypt data on the device isgenerated using a passphrase or biometric data supplied by the user (ifoffline access is required). It may be XORed with another key randomlygenerated and stored on the server side if offline access is notrequired. Key Derivation functions may operate such that keys generatedfrom the user password use KDFs (key derivation functions, notablyPassword-Based Key Derivation Function 2 (PBKDF2)) rather than creatinga cryptographic hash of it. The latter makes a key susceptible to bruteforce or dictionary attacks.

Further, one or more initialization vectors may be used in encryptionmethods. An initialization vector will cause multiple copies of the sameencrypted data to yield different cipher text output, preventing bothreplay and cryptanalytic attacks. This will also prevent an attackerfrom decrypting any data even with a stolen encryption key if thespecific initialization vector used to encrypt the data is not known.Further, authentication then decryption may be used, wherein applicationdata is decrypted only after the user has authenticated within theapplication. Another feature may relate to sensitive data in memory,which may be kept in memory (and not in disk) only when it's needed. Forexample, login credentials may be wiped from memory after login, andencryption keys and other data inside objective-C instance variables arenot stored, as they may be easily referenced. Instead, memory may bemanually allocated for these.

An inactivity timeout may be implemented, wherein after a policy-definedperiod of inactivity, a user session is terminated.

Data leakage from the application management framework 414 may beprevented in other ways. For example, when an application 610 is put inthe background, the memory may be cleared after a predetermined(configurable) time period. When backgrounded, a snapshot may be takenof the last displayed screen of the application to fasten theforegrounding process. The screenshot may contain confidential data andhence should be cleared.

Another security feature relates to the use of an OTP (one timepassword) 420 without the use of an AD (active directory) 422 passwordfor access to one or more applications. In some cases, some users do notknow (or are not permitted to know) their AD password, so these usersmay authenticate using an OTP 420 such as by using a hardware OTP systemlike SecurID (OTPs may be provided by different vendors also, such asEntrust or Gemalto). In some cases, after a user authenticates with auser ID, a text is sent to the user with an OTP 420. In some cases, thismay be implemented only for online use, with a prompt being a singlefield.

An offline password may be implemented for offline authentication forthose applications 410 for which offline use is permitted via enterprisepolicy. For example, an enterprise may want StoreFront to be accessed inthis manner. In this case, the client agent 404 may require the user toset a custom offline password and the AD password is not used. Gatewayserver 406 may provide policies to control and enforce passwordstandards with respect to the minimum length, character classcomposition, and age of passwords, such as described by the standardWindows Server password complexity requirements, although theserequirements may be modified.

Another feature relates to the enablement of a client side certificatefor certain applications 410 as secondary credentials (for the purposeof accessing PKI protected web resources via the application managementframework micro VPN feature). For example, an application may utilizesuch a certificate. In this case, certificate-based authentication usingActiveSync protocol may be supported, wherein a certificate from theclient agent 404 may be retrieved by gateway server 406 and used in akeychain. Each managed application may have one associated clientcertificate, identified by a label that is defined in gateway server406.

Gateway server 406 may interact with an Enterprise special purpose webservice to support the issuance of client certificates to allow relevantmanaged applications to authenticate to internal PKI protectedresources.

The client agent 404 and the application management framework 414 may beenhanced to support obtaining and using client certificates forauthentication to internal PKI protected network resources. More thanone certificate may be supported, such as to match various levels ofsecurity and/or separation requirements. The certificates may be used bythe Mail and Browser managed applications, and ultimately by arbitrarywrapped applications (provided those applications use web service stylecommunication patterns where it is reasonable for the applicationmanagement framework to mediate https requests).

Application management client certificate support on iOS may rely onimporting a public-key cryptography standards (PKCS) BLOB (Binary LargeObject) into the iOS keychain in each managed application for eachperiod of use. Application management framework client certificatesupport may use a HTTPS implementation with private in-memory keystorage. The client certificate will never be present in the iOSkeychain and will not be persisted except potentially in “online-only”data value that is strongly protected.

Mutual SSL may also be implemented to provide additional security byrequiring that a mobile device 402 is authenticated to the enterprise,and vice versa. Virtual smart cards for authentication to gateway server406 may also be implemented.

Both limited and full Kerberos support may be additional features. Thefull support feature relates to an ability to do full Kerberos login toActive Directory (AD) 422, using an AD password or trusted clientcertificate, and obtain Kerberos service tickets to respond to HTTPNegotiate authentication challenges. The limited support feature relatesto constrained delegation in Citrix Access Gateway Enterprise Edition(AGEE), where AGEE supports invoking Kerberos protocol transition so itcan obtain and use Kerberos service tickets (subject to constraineddelegation) in response to HTTP Negotiate authentication challenges.This mechanism works in reverse web proxy (aka corporate virtual privatenetwork (CVPN)) mode, and when http (but not https) connections areproxied in VPN and MicroVPN mode.

Another feature relates to application container locking and wiping,which may automatically occur upon jail-break or rooting detections, andoccur as a pushed command from administration console, and may include aremote wipe functionality even when an application 410 is not running.

A multi-site architecture or configuration of enterprise applicationstore and an application controller may be supported that allows usersto be service from one of several different locations in case offailure.

In some cases, managed applications 410 may be allowed to access acertificate and private key via an API (example OpenSSL). Trustedmanaged applications 410 of an enterprise may be allowed to performspecific Public Key operations with an application's client certificateand private key. Various use cases may be identified and treatedaccordingly, such as when an application behaves like a browser and nocertificate access is required, when an application reads a certificatefor “who am I,” when an application uses the certificate to build asecure session token, and when an application uses private keys fordigital signing of important data (e.g. transaction log) or fortemporary data encryption.

Application Customization

FIGS. 5-10, and the sections below, illustrate various embodiments andexamples relating to customizing applications in enterprise mobilitymanagement systems. Some examples are described in reference to mobileapplications for devices, such as mobile phones, personal digitalassistants (PDAs), tablet, and laptop computers. However, it should beunderstood that the concepts described herein are not limited to mobileapplications and mobile devices, but may be applied to other types ofcomputing devices as well. For example, customized software applicationsmay be developed for and distributed to personal desktop computers andother non-mobile computing devices, using similar (or the same)techniques described below for mobile applications and mobile devices.Customized applications also may be developed for and distributed todevices on other software platforms, such as television-based platforms(e.g., ANDROID applications for GOOGLE TV, etc.), automobile-based orvehicle-based software platforms, and the like, using similar or thesame techniques described below for mobile applications and mobiledevices (e.g., software development and modification tools, etc.).

Referring now to FIG. 5, another example is shown of an enterprisemobility management system 500. Some of the components of the mobilitymanagement systems 300 and 400, described above, have been omitted forthe sake of simplicity. The architecture of the system 500 depicted inFIG. 5 is similar in many respects to the architecture of the systems300 and 400, described above, and may include additional features notmentioned above.

In this example, enterprise mobility management system 500 includes amobile device 502 including a client agent application 504. In someembodiments the client agent application 504 may be known as, forexample, a master managed application, a client store application, orWorxHome from Citrix. The client agent 504 may interact with variousexternal systems, such as a Mobile Device Management (MDM) server 520,and an application controller 530 to access various enterpriseresources. For example, the client agent 504 may access the enterpriseapplication store 540 to allow selection and downloading ofapplications. The client agent may interact with these resources andother enterprises resources through a gateway server (e.g., includingAccess Gateway), not shown in FIG. 5. The enterprise application store540 may contain managed native applications, HDX (remotelyhosted/virtual) applications or desktops, Web and SaaS apps. Theenterprise application store 540 may also contain links, such as URLs orpointers, to the public application store 550 with unmanagedapplications, thus allowing the client agent 504 to also installunmanaged public store applications. For example, a nativevirtualization application, e.g., a client agent such as CITRIXRECEIVER, may be selected, downloaded and installed either as a managedapplication 519 from the enterprise application store 540 or as anunmanaged application 518 from the public application store 550. Inaddition both managed and unmanaged versions of a virtualizationapplication or any other native application may be installed at the sametime on the mobile device 502. In come embodiments, the Mobile DeviceManagement (MDM) server 520 and the application controller 530 could becombined into one server component. In some embodiments, multipleinstances of Mobile Device Management (MDM) server 520 and applicationcontroller 530 may exist in a cluster for reasons of load-balancing orfault-tolerance.

The client agent 504 also may support the installation and management ofapplications on the mobile device 502, such as native iOS, Android,Windows or Windows Phone applications. In this example, the mobiledevice 502 includes a mail application 506, browser application 508, atleast two line-of-business (LOB) applications 510, and a managed versionof a virtualization application, e.g., a client agent such as CITRIXRECEIVER, as another LOB application. These applications may be nativeapplications that execute locally on the device, and may be managed bythe client agent 504 and/or the AMF to provide policy driven managementcapabilities and features such as connectivity and SSO to variousenterprise resources/services. In some cases, the client agent 504 mayhandle primary user authentication to the enterprise resources andobtain policies from gateway server 406 to control the behavior of themanaged applications 410 on the mobile device 402. The Secure IPC linksbetween the client agent 504 and native applications 506-510 and 519 mayrepresent a management channel to allow the client agent 504 to supplypolicies to be enforced by an application management framework, thereby“wrapping” the native applications 506-510 and 519.

Prior to downloading and configuring the client agent 504 and otherapplications 506-510 and 519, the device 502 first may be enrolled inthe system 500 using a Mobile Device Management (MDM) system service.The processes by which mobile devices 502 may enroll in enterprisemobility management systems 500 are described in more detail below inreference to FIGS. 6-8. In some cases, the mobile device 502 may includean enrollment user interface 514 and/or client enrollment agent 516 tohandle device enrollment and unenrollment into various enterprisesystems 500. For example, certain mobile operating systems may includean enrollment user interface 514 and client enrollment agent 516configured to handle all device enrollment. In other cases, anenrollment user interface 514 and/or client enrollment agent 516 may notbe present on the device, in which case the device may contact anenterprise resource (e.g., Mobile Device Management (MDM) server 520) toenroll in the enterprise mobility management systems 500. Afterenrollment of the device 502, the client agent 504 and otherapplications may use an MDM client 512 to interact with the MDM server520.

FIGS. 6-8, discussed below, describe situations and use cases in whichvarious applications 504-510 and 519 may be customized within anenterprise system 500. In certain examples, a client agent application504 may be customized by an enterprise server (e.g., MDM server 520) inresponse to enrollment request by a device 502, before the client agent504 is provided to the device 502. In other examples, other customapplications may be generated and provided to an enrolled device 502, byconfiguring template applications (e.g., generic web-browserapplications, generic hosted applications, etc.) based on the specificdevice, user, and/or enrollment session.

After describing various situations and use cases in which applicationsmay be customized within an enterprise system 500, FIGS. 9-10 andcorresponding paragraphs discuss techniques and examples of customizingapplications.

Referring now to FIG. 6, an illustrative diagram is shown of a processof enrolling a user device into an enterprise system. The features andmethods described below in reference to FIG. 6 may be performed by acomputing device or combination of devices, such as the variouscomputing devices and systems shown in FIGS. 1 and 2, and may beimplemented within various different types of enterprise systems andother computing systems, such as the illustrative mobility managementsystems shown in FIGS. 3-5. For example, the steps of FIG. 6 may bedescribed in reference to a new mobile device 502, such as a newsmartphone, PDA, tablet computer, laptop computer, or the like,requesting enrollment in an enterprise system 500. System 500 may be amobility management system of a company or other enterprise, and thesteps discussed in FIG. 6 may be performed by one or more enterpriseresources of the company, such as the MDM server 520, applicationcontroller 530, and/or enterprise application store 540.

In step 601, a request is received by an enterprise resource (e.g., MDMserver 520) to enroll a client mobile device 502 into the enterprisemobility management system 500. Enrollment requests may be initiated bya user of the mobile device 502, for example, by selecting or typing inan enrollment URL link provided by the user's employer via an email,short messaging service (SMS) message, or other technique, to invite theuser to enroll in the company's enterprise mobility management system500. Enrollment requests may also be initiated by a user of the mobiledevice 502 by directly launching the enrollment user interface 514,which may invoke the client enrollment agent 516. For example, a user ofa Windows Phone device may directly go to the phone Settings menu andlaunch the Company Apps or Workplace menu to enroll the device by addingan enterprise (workplace) account. The enrollment URL may also beretrieved from the MDM server 520 or another enterprise network serviceusing an e-mail-based discovery, for example based on domain name system(DNS) lookup query. The enrollment URL may correspond to the MDM server520 or other enterprise resources (e.g., the application controller 530,an access gateway, etc.) In step 602, after receiving the enrollmentrequest from the device 502, the MDM server may require the device userto authenticate with valid user credentials (e.g., a company networkusername and password, or e-mail address and password). Validation ofuser credentials may be handled by the MDM server 520, or a gatewayserver including gateway services.

In step 603, if the user credentials received from the mobile device 502are valid (602:Yes), the MDM server 520 may generate a unique sessioncookie based on a device identifier of the requesting device 502 and/oran enterprise identifier (or publisher identifier) associated with thespecific enterprise (e.g., the employer, company, or other entitycontrolling the enterprise system 500). The MDM server 520 may generatethe session cookie (e.g., an encryption key or other unique number)using both the unique device ID and a unique enterprise/publisher ID.Therefore, different devices 502 enrolling into the same enterprise 500may receive different session cookies, and the same device 502 enrollinginto the different enterprises 500 may receive different sessioncookies. Additionally, in some cases, the session cookie generated instep 602 may be unique to an enrollment session, so that the same device502 requesting enrollment in the same enterprise 500 on multipledifferent occasions (e.g., after a delay or unenrollment) may receivedifferent session cookies during the different enrollment processes.

In step 604, the session cookie generated by the MDM server 520 may beprovided or otherwise made available to the mobile device 502. In somecases, MDM server 520 may transmit the session cookie to the mobiledevice 502 during device enrollment using an MDM protocol. The mobiledevice 502 and/or the MDM client 512 may securely store the sessioncookie such that it is available only to the client agent application504, or such that the session cookie may be available to the clientagent 504 and/or other native and LOB applications 506-510 and 519. Inother examples, the session cookie may be embedded into the client agentapplication 504 at the MDM server 520 before the client agent 504 isprovided to the device 502 in step 606, thereby creating a customizedclient agent 504 by wrapping the client agent 504 with the sessioncookie to allow the client agent 504 to automatically access the MDMserver 520 with a seamless SSO during a first-time use (FTU) of theclient agent 504 after enrollment. In some embodiments, wrapping orembedding of the session cookie into the client agent application 504may be the preferred or the only available approach, e.g. if the MDMprotocol and MDM client 512 are proprietary for the mobile device 502and its operating system and cannot be modified or updated.

In step 605, the MDM server 520 may embed one or more enterprise URLsinto the client agent 504, thereby creating a customized client agent504 by wrapping the client agent 504 with the URLs to the enterpriseservers and other resources that the device 502 is permitted to accesswithin the enterprise system 500. For example, in some embodiments, thevarious URLs for enterprise servers and resources may be embedded in theapplication manifest file of the client agent 504. In other examples,the various enterprise URLs need not be wrapped into the client agentapplication 504, but may be made otherwise available. For example, theMDM server 520 may transmit the various URLs for enterprise servers andresources to the mobile device 502 during device enrollment using an MDMprotocol. The mobile device 502 and/or the MDM client 512 may securelystore the various URLs for enterprise servers and resources such thatthey are available only to the client agent application 504, or to theclient agent 504 and/or other native and LOB applications 506-510 and519. In some embodiments, wrapping or embedding of the variousenterprise URLs into the client agent application 504 may be thepreferred or only available approach, e.g. if the MDM protocol and MDMclient 512 are proprietary for the mobile device 502 and its operatingsystem and cannot be modified or updated.

In step 606, the MDM server 520 (and/or other resources in enterprisesystem) may complete the enrollment process by providing the clientagent application 504 and/or other applications to the device 502. Asnoted above, the client agent 504 transmitted to the device 502 may becustomized in various ways based on the device 502, user, and/orenrollment session. For example, the client agent 504 may be embeddedwith the unique session cookie, or may include software to access theunique session cookie from a secure memory of the device 502. The clientagent 504 also may be embedded with various enterprise URLs to the MDMserver 520, application controller 530, application store 540, and thelike, or may include software to access the enterprise URLs from asecure memory of the device 502.

In other examples, the client agent application 504 may be customized toinclude other features to enable seamless SSO during first time use. Forinstance, a separate encryption key, different from the session cookie,may be embedded into the client agent 504 during enrollment. Thisembedded encryption key may be used to secure the IPC between the clientagent 504 and other applications 506-510 and 519. Informationinstructing the client agent application 504 to set SSL certificatetrust also may be embedded into a customized client agent 504 before orduring the enrollment process.

Additional information, such as user certificates and applicationconfiguration information, also may be embedded into the client agent504 before it is transmitted to the device 502. User certificates andapplication configuration information (e.g., mail server accountconfiguration data) may allow the applications 504-510 and 519 on thedevice 502 to immediately access enterprise resources such as emailservers, file share servers, and the like, without needing toauthenticate or provide account configuration data to these enterpriseresources during the initial access request.

First-time use policies also may be embedded into the client agent 504during the enrollment process, for example, policies identifying whichauthentication methods should be used, the network and VPN settings,logging policies, data encryption and containment policies, and thelike. By embedding first-time use policies that are specific to a user,device, and/or enrollment session into the client agent 504 before it istransmitted to the device 502, the enterprise applications 504-510 and519 on the device may initialize offline, i.e., without a live networkconnection when an application is launched for the first time.

Additional data may be embedded into the client agent 504 during theenrollment process to configure the user interface, user experiencebehavioral settings, and branding of the client agent 504 and otherapplications 506-510 and 519. For example, the MDM server 520 maydetermine user-specific client agent preferences, such as subscribedapplications, applications pinned to the start screen, arrangements ofapplications, background colors and UI preferences of applications,logging preferences, etc. The MDM server 520 may receive user interfaceand user experience preferences from other devices enrolled by the userinto the enterprise system 500, while additional settings may beconfigurable by the user or an administrator for specific users, usergroups, device types, etc.

As shown in step 606, other applications may be provided to the device502 during or after the enrollment process, other than the client agent504. Such applications may include mail applications 506, browserapplications 508, various line-of-business applications 510, and amanaged version of a virtualization application 519. The set ofapplications 506-510 and 519 provided to a device 502 upon enrollment,along with the configurations and customizations of those applications,may depend on the user, device, and enrollment session. Factors such asthe capabilities of the device 502, the employee's title, securityclearance level, seniority within the company, etc., may be used todetermine the set of applications 506-510 and 519 and configure theapplications during enrollment process. The same or similarconfiguration and customization use cases and data embedding techniquesdiscussed already for the client agent 504 can also be applied to othermanaged applications, such as the set of managed LOB applications506-510 and 519.

As indicated at the bottom of FIG. 6, steps 601-606 may be performedduring the device enrollment process, prior to the initial launch by theuser of the client agent 504 on the device 502. Referring now to FIG. 7,steps 701-703 may be performed by the MDM server 520 and/or otherenterprise servers or resources after the enrollment of the device 502in the enterprise system. For example, the features and examplesdiscussed below in reference to FIG. 7 may be performed in response tothe initial launch by the user of the client agent application 504 afterenrolling the device 502.

In step 701, after user initially launches the client agent application504 after enrolling device 502, the client agent 504 may automaticallyinitiate a communication session with the MDM server 520 or otherenterprise resources. As discussed above in FIG. 6, the appropriateenterprise URLs may be embedded with the client agent 504, or otherwisemade available to the client agent 504 (e.g., in the secure memory),during enrollment. Therefore, when the user initially launches theclient agent 504, the user need not determine or manually input the URLto connect to any available enterprise resources. Instead, the clientagent 504 may be configured to automatically retrieve the URL of the MDMserver 520, application controller 530, access gateway, or the like, andinitiate communication without any explicit action from the user. Thecommunication received from the client agent 504 in step 701 also mayinclude the unique session cookie generated during (or before) theenrollment process for the device 502. As discussed above, the sessioncookie may be an encryption key or other unique number generated by theMDM server 520 during enrollment, based the device ID and anenterprise/publisher ID.

Because the session cookie is only provided to the device 502 after asuccessful user authentication (see steps 602 and 604) during theenrollment process, a validation of the session cookie by the MDM servermay confirm the user's identity and access permissions. Accordingly, instep 702, the MDM server 520 may compare the session cookie receivedfrom the device 502 to the session cookie created in step 603, in orderto authenticate the user and device. In some cases the steps of FIG. 6may be performed by one enterprise resource (e.g., MDM server 520),while the steps of FIG. 7 may be performed by a different enterpriseresource (e.g., application controller 530 and/or an access gateway). Insuch examples, after creating the session cookie in step 603, the MDMserver 520 may transmit or otherwise make available the session cookieto the application controller 530 and other enterprise resources.

Thus, by comparing the session cookie received from the device 502 instep 702, to the session cookie created during enrollment of the devicein step 603, the MDM server 520 may authenticate the deviceautomatically and without needing the user to re-input authenticationcredentials. However, as noted above, in some cases the session cookiemay be available to other applications 506-510 and 519 on the device502. Therefore, one or more additional features may be implementedduring the session cookie validation in step 702, in order to prevent amalicious application on the device from accessing the MDM server 520 orother enterprise resources (e.g., a malicious LOB application 510pretending to be the client agent 504 by using the session cookie). Inorder to protect against such security breaches, in some cases, thesession cookie may be embedded directly into the client agent 504 sothat it is inaccessible to any other application 506-510 and 519. Insuch cases, because the session cookie could not be used for secure IPCbetween the client agent 504 and other applications 506-510 and 519, adifferent shared encryption key may be generated for performing secureIPC between applications 504-510 and 519. In other examples, the sessioncookie may be made available to other applications 506-510 and 519 onthe device 502 (and thus may be used for the secure IPC), but the clientagent 504 may be embedded during enrollment with another shared secret(e.g., a unique number or certificate) that also may be transmitted bythe device in step 701 and validated by the MDM server 520 in step 702,in order to confirm that a malicious application is not posing as theclient agent 504.

Additionally, in some implementations, unique session cookies generatedbefore or during the enrollment process for a device may haveconfigurable expiration times. The expiration times may be based on thetime the device was enrolled and the session cookie was provided to thedevice 502. If the user does not launch the client agent 504 within thedetermined time window (e.g., 1 hour, 2 hours, 1 day, etc.), then theMDM server 520 will expire the session cookie, and the user may beprompted to input valid authentication credentials during first time usein order to authenticate successfully. Alternatively, the device 502 mayre-enroll and receive a newly generated session cookie, and then launchthe client agent 504 to automatically connect to the MDM server 520. Insome embodiments the client agent 504 may be launched automatically,i.e. without explicit user action, immediately after the client agent504 is provided to the mobile device 502 as part of the enrollmentprocess in step 606. For example, the client agent 504 may be launchedby the MDM client 512. In other examples, the client agent 504 may belaunched by the mobile device 502 in response to push notificationsissued by the MDM server 520 or application controller 530 or anotherenterprise service. In some embodiments the automatic launch of theclient agent 504 could be configured to occur prior to the expiration ofthe session cookie, thus ensuring that the user does not have to inputauthentication credentials again or initiate re-enrollment of the device502.

In step 703, after a successful validation of the session cookie(702:Yes), the user's identity has been established and the MDM server520 may provide the device 502 with one or more client certificatesand/or user certificates to use for future authentication to the MDMserver 520 and other enterprise resources. Client certificates, unlikesession cookies, may be longer lasting and might not have an expirationdate. Client certificates may be used by the client agent 504 for futurerequests to the MDM server 520. Similarly, user certificates may allowthe various applications 504-510 and 519 to authenticate to differentprotected resources within the enterprise system 500, such as emailservers, file share servers, and the like. Applications 504-510 and 519may use different user certificates, and multiple certificates may besupported to match various levels of security and/or separationrequirements. For example, user certificates may be used by the mailapplication 506 and browser application 508, along with LOB applications510 and a managed version of a virtualization application 519 that useweb-service style communication patterns with https requests mediated bythe AMF.

Additionally, in step 703, the applications 504-510 and 519 installed onthe device 502 may be configured to use the various client certificatesand/or user certificates received from the MDM server 520, without anyexplicit action by the user except for the initial launch of the clientagent application 504. As discussed above in FIG. 6, clientcertificates, user certificates, and/or application configurationinformation may be embedded within the client agent 504, or otherwiseprovided to the device 502 during enrollment. In these examples, anysuch client certificates, user certificates, and/or applicationconfiguration information made available to the device 502 duringenrollment need not be transmitted in step 703.

Referring now to FIG. 8, an illustrative diagram is shown of a processperformed in response to the initiation of a client agent application504, after enrollment of a device 502 in an enterprise system 500. Steps801-814 in FIG. 8 may be performed by the client agent application 504on the mobile device 502. These steps may generally correspond to thesteps 701-703 in FIG. 7, which are concurrently performed on the MDMserver 520.

In step 801, a user may launch a client agent 504 (e.g., a company hubsoftware application) on the mobile device 502. In some embodiments, instep 801, the client agent 504 may be launched automatically. Forexample, as discussed above in FIG. 7, the client agent 504 may belaunched by the MDM client 512, or by the mobile device 502 in responseto push notifications issued by the MDM server 520 or applicationcontroller 530 or another enterprise service. In step 802, the clientagent 504 may determine if Mobile Device Management (MDM) has beenconfigured for the device 502. If the device 502 has been MDM configured(802:Yes), that indicates that the device has previously beensuccessfully enrolled and provisioned with the appropriate applications,client and user certificates, configuration settings, policies, etc.,within the enterprise system 500. In this case, there is no need for thedevice 502 to contact the MDM server 520, and in step 803 the enterpriseapplications available to the user are presented via the client agent504.

If the device has not been MDM configured (802:No), that may indicate afirst-time use of the client agent 504, in which case addition functionsmay be required to configure the device 502 for Mobile Device Managementusage. In step 804, the client agent 504 may attempt to retrieve the URLof the MDM server 520 from its application manifest. As discussed abovein FIG. 6, the URL of the MDM server 520 and/or additional URLs ofenterprise resources may be added to secure memory on the device 502,embedded into the client agent application 504, or otherwise madeavailable to the device 502 during enrollment. In this case, if theclient agent 504 cannot retrieve the URL of the MDM server 520 (805:No),then it may be configured to prompt the user to enter the URL in step806. However, if the client agent 504 successfully retrieves the URL ofthe MDM server 520 (805:Yes), then it may initiate a communicationsession with the MDM server 520 and provide a publisher-device ID to theMDM server 520 in step 807. The publisher-device ID in this example maycorrespond to a unique session cookie provided to the device duringenrollment, or other unique number based on the device ID and anenterprise ID (or publisher ID).

After the MDM server 520 receives the publisher-device ID, it mayrespond to the client agent 504 indicating whether or not thepublisher-device ID (e.g., session cookie) was successfully validated bythe MDM server 520. Examples of validating session cookies by the MDMserver 520 are discussed above in reference to step 702. If the MDMserver 520 indicates that the publisher-device ID was not successfullyauthenticated (808:No), then the client agent 504 may be configured toprompt the user to manually input user credentials in step 809 forauthenticating to the MDM server 520. However, if the MDM server 520indicates that the publisher-device ID was successfully authenticated(808:Yes), then the client agent 504 may connect to the MDM server 520to retrieve the appropriate MDM configuration data for the device anduser in step 810. The MDM configuration data retrieved in step 810 mayinclude, for example, client certificates, user certificates,application settings, enterprise policies, etc., which may be based onthe specific user, user group, device, or other factors. Additionally,one or more custom applications may be provided to the mobile device 502in step 810.

In step 811, the client agent 504 determines if the device 502 isconfigured for MDM only, or for both MDM and Mobile ApplicationManagement (MAM) capabilities. If the device 502 is configured only forMDM (811:Yes), then the initial MDM configuration of the device 502 iscomplete, and the enterprise applications available to the user may bepresented via the client agent 504 in step 812. If the device 502 isconfigured for both MDM and MAM (811:No), then in step 813 the clientagent 504 initiates a communication session and discovery process withthe application controller 530 and/or access gateway, and the enterpriseapplications available to the user may be presented via the client agent504 in step 814.

As discussed above, FIGS. 6-8 describe various situations and use casesin which enterprise applications may be customized for users within anenterprise system. In a first set of use cases and examples, FIGS. 6-8describe customizing a client agent software application 504 in variousways, after receiving a device enrollment request. For example, URLscorresponding to MDM servers 520, application controllers 530, gateways,and other enterprise system resources, may be embedded in a client agentapplication 504 before providing the client 504 to a user's device 502.The client agent 504 also may be customized by embedding (or otherwisemaking available) a session cookie based on a device identifier and/orenterprise identifier, to support seamless SSO during first-time use.Other examples of customizing the client agent 504 before it is providedto an enrolled mobile device 502 are described above. The same orsimilar configuration and customization use cases and data embeddingtechniques discussed already for the client agent 504 can also beapplied to other managed applications, such as the set of managed LOBapplications 506-510 and 519. Some customizations could be transferredfrom the client agent 504 into managed LOB applications 506-510 and 519at the mobile device 502 via the AMF and Secure IPC. However, it isbeneficial for LOB apps to be customized prior to deployment, so thatsuch customizations could take effect immediately upon LOB app launchand first time use, and before any interactions of a LOB app with theclient agent 504, or any enterprise service, which requires networkaccess. For example, a LOB app can be customized with secure by defaultpolicies, shared encryption keys for secure IPC with the client agent504 and other managed apps, etc. Additionally, in a second set of usecases, other enterprise applications may be customized to appear asnative applications after deployment on the user's device 502. Suchcustomized applications may include packaged web applications (e.g.,based on a generic web browser application) or specific implementationsof hosted applications in an enterprise data center (e.g., based on aclient agent application).

Having described various situations and use cases in which enterpriseapplications may be customized within an enterprise system, FIGS. 9-10and the following paragraphs describe techniques and examples ofcustomizing applications.

Referring now to FIG. 9, an illustrative diagram is shown of a processof building a customized mobile application bundle based on a mobiletemplate application. The features and methods described below inreference to FIG. 9 may be performed by a computing device orcombination of devices, such as the various computing devices andsystems shown in FIGS. 1 and 2, and may be implemented within variousdifferent types of enterprise systems and other computing systems, suchas the illustrative mobility management systems shown in FIGS. 3 and 4.

The example build process shown in FIG. 9 accepts mobile applicationcode 901 and enterprise application customization software tools 902.The mobile application code 901 in this example may correspond to one ormore executable software components or to application code that has notbeen built into an executable component. For example, the mobileapplication code 901 may be an executable native mobile applicationbuilt by an organization for use within the organization, or built anddistributed by an independent software vendor (ISV). In such cases, themobile application code 901 may correspond to a previously publishedexecutable application, which has been signed and certified fordistribution through one or more application stores. Alternatively, themobile application code 901 may be unbuilt software code, for example,code during an application development process. Additionally, asdiscussed below, the mobile application code 901 may correspond to atemplate application, such as a configurable stub application designedto allow users to easily create customized mobile applications forenterprise systems. Such template applications may themselves beexecutable applications (e.g., a generic or stub web browserapplication, a generic or stub single-session client executionenvironment application, etc.), or may take the form of a templateapplication factored out into a binary software development kit (SDK).

The enterprise application customization software tools 902 in FIG. 9may be a software toolkit provided to organizations, ISV's, or othersoftware application developers. In some examples, the software tools902 may include a header file and library to allow applicationdevelopers to create customized mobile applications for enterprisesystems. The tools 902 library may include application programminginterfaces written in C, Objective-C, C++, C#, or other suitableprogramming language. In some cases, the customization software tools902 may include a command-line executable tool 902 that receives aninput parameter identifying a mobile template application 901, andadditional input parameters specifying one or more features for thecustomized application, such as the customized application name, bundleidentifier, application icons, friendly names, application service URIs,application specific policies, etc. Customization tools 902 may thengenerate the customized application package, for example, a .IPAexecutable for APPLE mobile devices, a .APK executable for GOOGLEANDROID mobile devices, a .XAP or .APPX executable for Windows Phone orWindows mobile devices, etc. In other examples, the customization tools902 may include a wizard 902 or other user interface screens to allowusers to specify the various features for the customized application. Instill other examples, the software tools 902 need not include acommand-line tool or a wizard, but instead (or in addition to) may beimplemented as a service. For example, a service 902 containing thefunctionality to update or convert a mobile template softwareapplication to a customized mobile application may be integrated intothe publishing flows of template mobile applications.

During the code modification and build process 903, the customizationapplication tools 902 may be used to modify the mobile application code901, before building (or rebuilding) the code into an executablecustomized mobile application. As noted above, the mobile applicationcode 901 may correspond to an executable software component (e.g., anative mobile application, a template application, a binary SDK, etc.)or to unbuilt and not executable software code. Thus, if the mobileapplication code 901 is a executable application, the modification andbuild process 903 may include opening (or decomposing) the existingapplication bundle, modifying the application code 901 by embeddingcustom code and/or modifying the existing application code. In somecases, user-specific assets may be inserted into the code, such asuser's certificates, user's initial set of policies, user's sessiontoken, etc.). Additionally, the template application code may bemodified to change the application characteristics, for example, theapplication name, application icon, user interface components,application-specific policies, service registration, service URIs, andthe like, to implement the desired characteristics of the customapplication.

If the mobile application code 901 is unbuilt and not executablesoftware code, for example, if the mobile application code 901 if underdevelopment by an ISV or organization associated with an enterprisesystem, then the custom code and/or application characteristics may beinserted into the code without needing to first open an executableapplication bundle. Additionally, in some template applications 901(e.g., a generic or stub application, or a binary SDK corresponding to ageneric or stub application), the code to implement various customizedapplication features might already be included in the template.

During the modification and build process 903, the customizationapplication tool(s) 902 may be configured to add certain functionalityto the template application (e.g., custom binaries, modification ofimport address tables, insert of user assets, etc.), and to updatecertain characteristics of the template application (e.g., customapplication name, friendly name, icon, user interface features,application-specific policies, service registration, etc.). For example,the customization software components 902 may receive a templateapplication 901 from an application source (e.g., a template repositoryin an enterprise application store or MDM server 520), decompile thetemplate application, change the application characteristics tocustomize the application, augment the application with a set ofinstructions that impose control based on a set of policies, and thenrecompile the application to form a customized application.

The code modification and building process 903 may be performedautomatically by one or more software tools 902, or may include one ormore steps involving user input and/or user interaction. In someexamples, a software tool 902 may correspond to a command line utilityor service that is capable of receiving template application code 901(in the form of one or more binary executables and/or source code),opening the application bundle, modifying the application code 901, andbuilding (i.e., bundling and signing) the executable customized mobileapplication, all without needing any user interaction or input. In otherexamples, user input and/or user interaction may be received and usedduring the process 903 of modifying the application code 901 andbuilding the customized mobile application. For example, a command lineutility 902 may allow users to specify arguments that control thecustomization of the template application, including the custom featuresand functionalities that will be inserted into the application code 901.For example, a user may specify an application name, icon, userinterface features, and constraints and policies that will beimplemented to control the custom application in an enterprise system(e.g., data encryption policies, secure communication policies, resourceaccess constraints, etc.). The software tools 902 also may include awizard 902 or other user interfaces to receive input from users (e.g.,application developers or distributors, or enterprise system usersconverting template applications to custom application) specifying thecustom features and functionalities to be applied to the templateapplication. For instance, user input may be received and used tocustomize the functional features, look and feel, and publicationinformation of applications generated based on template applications(e.g., web-based applications and client execution environmentapplications).

After the modifying the application code 901, the code may be compiledand built (or recompiled and rebuilt in the case of native mobileapplications and the like) using one or more compilation and buildsoftware tools (e.g., the XCODE suite for developing iOS applications,or Visual Studio tools for developing Windows Phone or Windows mobiledevices). The build process illustrated in FIG. 9 may include atesting/validation phase, in which some or all of the tests normallydone during an application wrapping process may be performed. Suchtesting and validation may be performed on the software source codebefore the code is built (or rebuilt) into an executable application,and/or may be performed on the executable application after thecompilation/build process. In some examples, additional testing andvalidation may be performed to ensure that the customized mobileapplication 904 is compatible with one or more enterprise systems. Forinstance, if a customized mobile application is intended to be offeredand supported by an enterprise system, then a test utility may be usedduring or after the build process 903 to confirm that the customapplication is compatible with the access gateway and/or infrastructureof the intended enterprise system.

As shown in FIG. 9, the process of modifying and building 903 theapplication code may produce a customized mobile application bundle 904.The application bundle 904 may include one or more executable binariesfor the customized mobile application (e.g., .IPA files for APPLE mobiledevices, .APK files for GOOGLE ANDROID mobile devices, .XAP or .APPXfiles for Windows Phone or Windows mobile devices, etc.), as well as oneor more metadata files associated with the application (e.g., XML files,text files, or other metadata formats). As discussed above, customizedmobile applications may be user-specific and/or device-specificapplications that may be provided to mobile devices after enrollment. Insome cases, the executable binaries for the customized mobileapplication 904 also may be provided to different application stores(e.g., enterprise application stores, public application stores, etc.).As discussed above, an enterprise application store (e.g., applicationstore 378) may be populated with enterprise applications by anapplication controller 374, including secure and enterprise-specificapplications.

Additionally, it should be understood that the various apparatuses ofthe computing environments shown herein may be computerized andcommunicate via electronic signals. For example, each computerizedapparatus described in relation to FIG. 9 may include a communicationsinterface to connect to a communications medium such as a computernetwork, memory to cache and/or persistently store information, andprocessing circuitry to execute an operating system and localapplications, including some or all of the components discussed above inreference to FIGS. 1 and 2.

In certain embodiments, a user of mobile device may browse customizedand/or non-customized applications offered by an application storeserver 540 via a client agent application 504 or a virtualizationapplication 518, 519 (e.g., an application store application) installedon the mobile device 502. For example, when a user of a mobile device502 wishes to acquire an application, the user may direct a client agent504 on the mobile device 502 to request an appropriate application fromthe application store server 540. The application store server 540 mayrespond to the request by providing the application to the mobile device502, and the mobile device user may then install the application. Whenthe application is a customized mobile application, a customizationprocess may be performed, such as the process described above inreference to FIG. 9, at the application store server 540, locally at themobile device 502, and/or by other components within the enterprisemobility management system 500.

Referring now to FIG. 10, an example method is shown in which anapplication is modified and configured to create a customizedapplication based on customization parameters determined by anenterprise administrator and/or by an enterprise user. In this example,two separate customization processes may be performed before anenterprise application is provided to an enterprise user; a firstcustomization based on enterprise parameters defined by an administratoror policies of an enterprise system, and second customization determinedby the characteristics of the specific users, specific devices, and/orspecific enrollment sessions to which the application will be provided.In either and/or both of the customizations described in FIG. 10,software tools 902 may be used as described above to create a newcustomized mobile application by modifying and configuring a templatemobile application.

In step 1001, an application template may be identified to be used forcreating a customized application for an enterprise system. In somecases, an administrator of an enterprise system may identify anapplication template to be customized and made available to some or allusers of the enterprise system. The template application may be, forexample, a packaged web application, an application hosted in anenterprise data center (e.g., an application that is accessed using theHDX/ICA or other display remoting protocol), or an application that isused to access HDX/ICA or other virtual applications, such as forexample virtualization applications 518, 519, or any other playerapplication for rendering virtual applications, or any other type ofgeneral application for which an application template (e.g., generic orstub application) may be created.

In step 1002, a set of customization parameters may be selected tocustomize the application template for the enterprise system. Theparameters may be selected in step 1002 by an enterprise administratoror based on enterprise policies to customize the template applicationfor use by enterprise users. The customization parameters may include,for example, a custom application name, a friendly name, an applicationicon, one or more user interface component specifications,application-specific policies, service registrations, service URIs, andthe like. Additionally, a template application may be customized byadding source code or executable code (e.g., custom binaries) and bymodifying import address tables to support additional functionality.Thus, the customization parameters may identify locations of source codefiles or custom binaries, or the customization parameters may includeaddress table data.

As discussed below, the set of customization parameters selected in step1002 may be used to define a new enterprise application for theenterprise system's catalog, which may be provided to users via theenterprise application store 540 or may be automatically pushed to themobile devices of certain users during the enrollment process or atother times by the enterprise system servers. Thus, the customizationparameters selected in step 1002 may be, for example, parameters thatcustomize an application's name, the look and feel of the application,or parameters that enable the application to connect to the enterpriseservers or server-based applications of the enterprise system.

As discussed above in reference to FIG. 9, various software tools 902may be used to receive input in steps 1001 and 1002 corresponding to theidentification of a template application and customization parametersfor creating a customized mobile application. Such tools may beautomated (e.g., software components at the MDM server 520 configured toautomatically create and provide custom applications to user devices502), or interactive user-driver tools. Similarly, the identification oftemplate applications and customization parameters in steps 1001 and1002 may be provided from a number of different entities in differentembodiments and scenarios. For example, companies may develop mobilebusiness applications that are customized for individual employees orgroups of employees. Such customized applications may be generated andprovided automatically by the business, for example, in step 606, inresponse to the enrollment of a mobile device by a company employee. Forexample, an MDM server 520 may use device and/or user identifiersreceived in step 601 to determine the parameters of the customizedapplications. Additionally, as discussed below, employees in one line ofbusiness (e.g., engineering, accounting, human resources, etc.) mayreceive one set of customized applications in step 606, while employeesin another line of business may receive another set of customizedapplications, etc. Thus, the set of customized applications provided toan employee's device upon enrollment also may depend on the employee'stitle, security clearance level, seniority within the company, and otherfactors. In still other examples, the parameters and preferences forcreating customized applications may be provided in step 1002 byindependent software vendors (ISVs) developing customized mobileapplications for public consumers.

In step 1003, a first customization process may be performed based onthe template application identified in step 1001 and the customizationparameters selected in step 1002. The template application identified instep 1001 may be retrieved and be opened, for example, by decompiling ordecomposing the application into readable and/or editable code, ifnecessary. After retrieving and opening a template application, theapplication may be modified based on the customization parametersselected in step 1002 (e.g., application name, user interfacecustomization, etc.) and/or any additional custom functionality selectedfor the custom enterprise application.

In some cases, the retrieval and opening of the template application maybe performed by software tools 902, discussed above. In such cases, atemplate application such as generic application or stub application mayinclude application code designed for a specific type of application(e.g., web applications, hosted enterprise applications, etc.) that maybe easily configured, built, and deployed as a separate customizedmobile application. For example, an application template may be singlepurpose application (e.g., a single tab web browser application, asingle session hosted enterprise application, etc.) with the underlyingcode to execute as a mobile application, and with a set of defaultconfiguration parameters that may be changed to modify the functionalityof the application. For example, the configuration parameters of anapplication template may define the features and functionality ofapplication, and may correspond to the customization parametersidentified in step 1002 (e.g., constraints and policies that may beimplemented to control the application in an enterprise system), thelook and feel of the application user interface (e.g., application skin,text, supported features, etc.), and data for publication of theapplication (e.g., application name, friendly name, icon, etc.).Template applications may be designed and written so that suchconfiguration parameters may be easily inserted and/or modified withinthe template by a software tool 902.

Thus, in step 1003, a template application may be provided as input to asoftware tool 902 used to create a managed application 904. In variousexamples, the software tools 902 may correspond to a software toolkit902 provided to organizations, ISV's, or other software applicationdevelopers. In such cases, one or more template applications may beprovided along with the software toolkit 902, or may be downloadablefrom a separate location. In other examples, template applications mightnot be directly available to developers, but may be available indirectlyvia a software tool 902 such as a command-line tool, wizard, or otheruser interface software tool. For example, a user may interact with asoftware wizard 902 to select a template application and providecustomization parameters, after which the software wizard 902 mayretrieve and modify the underlying application template in accordancewith the customization parameters provided by the user.

Certain types of template applications may be web application templates(or web browser template applications). In some cases, a web applicationtemplate may be a browser application stub, or may be a web browserapplication factored out into a binary SDK. Web application templatesmay be based on a native web browser application supported by a mobileplatform, such as an iOS web browser, WINDOWS PHONE web browser, orANDROID web browser, and thus may include the traditional web browsingfunctionality. Web application templates also may include the code to bepackaged as managed applications, so that the web browsing it supportsmay be performed using the security controls provided by an enterpriseframework (e.g., network connectivity via micro VPN) to allow the webbrowser application to access Intranet resources as well as Internetresources.

In some examples, the customization in step 1003 of a web applicationtemplate may include changing or removing typical web-browser navigationcontrols, address bar, menus, or other user interface features used byweb browsers, so that the customized web application may have a specificlook-and-feel different from a standard web browser. In differentcustomizations of web application templates, different user interfacecomponents (e.g., menus, navigation controls, scroll bars, etc.) may beincluded or not included in the modified application code to providedifferent options for creating web applications. Additionally, thecustomization of a web application in step 1003 may include configuringvarious controls and security features of the internal applicationbrowser, for example, enabling or disabling scripting (e.g., Javascript)or applets (e.g., Java Applets), and enabling or disabling legacybrowser behaviors and/or other browser features.

In other examples, a template application may be a hosted enterpriseapplication template. A hosted enterprise application template may bebased on a client execution environment application configured toprovide a user interface for an application hosted in an enterprise datacenter. Hosted enterprise application templates may include, forexample, the code from a client execution environment engine along withthe user interface display controllers for the client executionenvironment session view. Applications generated from a hostedenterprise application template may be configured to access anenterprise data center using, for example, HDX/ICA display remotingprotocols, and thus may be deployed through the gateway of an enterprisesystem (e.g., gateway 406), just like other native applications on themobile device 402. In some examples, hosted enterprise applicationtemplates may be customized in step 1003 so that they operate only on asingle session, rather than supporting multi-session applications, sothat the customized hosted application generated from the template mayhave the look-and-feel of a single customized application.

As discussed above, a template application may include basic underlyingfunctionality (e.g., web browsing, connection and hosting from anenterprise data center, etc.), but might not include the specificcontent or configuration of the customized application desired byenterprise administrators and/or enterprise users. Thus, themodification of the template application code in step 1003 may includecustomizing the functionality of the application (e.g., features,behaviors, etc.), customizing the appearance of the application (e.g.,look-and-feel, providing a name and icon for publishing the application,etc.), and/or customizing how the application will be managed orcontrolled within the enterprise system (e.g., security features,constraints and policies, etc.).

For web application templates, the customization parameters received instep 1002 may include, for example, a name for the web application, anicon for publishing the web application, and a set of uniform resourcelocators (URLs) that define or limit the set of web pages or webresources for which the customized web application can be used. The setof URLs received to customize a web application may take the form of aURL list, or a set of base URL patterns input by the user viacommand-line arguments, a wizard, an input data file, or other userinterface in step 1002. The customization parameters received for a webapplication template also may include parameters for security/managementpolicy control, such as whether the web application will be permitted totunnel back through the network, whether the web application willsupport copy and paste functionality internally and between otherapplications, and a list of the mobile device hardware and facilities(e.g., the GPS system, microphone, or other sensors on the mobiledevice) to which the web application will have access.

In examples of a hosted enterprise application template, thecustomization parameters received in step 1002 may include a name andicon for the application, a specific hosted enterprise applicationcorresponding to the mobile application (e.g., when a customizedsingle-session managed application is to be created), parameterscorresponding to security/management policy controls for the hostedenterprise application, and parameters to configure the user interfacesof the hosted enterprise application.

The customized mobile application generated in step 1003 may be based onthe modifications to the template application code. In some examples,step 1003 may be similar to the build process 903, discussed above. Forinstance, one or more executable binaries corresponding to thecustomized mobile application (e.g., .IPA files for APPLE mobiledevices, .APK files for GOOGLE ANDROID, .XAP or .APPX files for WindowsPhone or Windows mobile devices, etc.) may be generated in step 1003,using compilation and build software tools, such as the XCODE suite fordeveloping iOS applications, or the Visual Studio tools for developingWindows Phone or Windows mobile devices, etc. In some cases, templateapplications may be designed so that customization parameters can beeasily added into the template application, for example, as entries in aconfiguration data file, to allow the application to be easily rebuiltand recertified.

In step 1004, the enterprise application customized in step 1003 may beselect by, or selected for, one or more enterprise users and/or mobiledevices in the enterprise system. In some cases, a customizedapplication may be published to an enterprise application store 540,from which users may browse and select the application to be downloadedto mobile devices 502. In other cases, enterprise administrators maydetermine which applications are distributed to various users and mobiledevices. Enterprise policies also may be used to automatically pushapplications to users and/or devices. For example, an enterprise policymay be implemented to push a specific customized enterprise applicationto all devices during the enrollment process or any time afterenrollment. Alternatively, some enterprise policies may push specificenterprise applications only to certain users and/or devices in theenterprise system, and not to other users and/or devices. For instance,a policy in an employer's enterprise system may be implemented to push acustomized application to only a subset of its employees' mobile devicesbased on one or more employee criteria (e.g., the employee's title, workgroup or company division, physical office location, security clearancelevel, seniority at the company, etc.), or based on one or more devicecriteria (e.g., device input capabilities such as touch screen or voicerecognition capabilities, device output capabilities such as screen sizeor graphics package, device memory and processing capabilities, devicemanufacturer and model, device operating system, etc.), or based on acombination of employee criteria and device criteria. In some examples,the enterprise system may be further configured to push a customizedenterprise application to specific users and/or devices only duringcertain enrollment sessions. Thus, the set of enterprise applicationsand/or the specific customizations pushed to a mobile device 502 of auser during a first enrollment session may be different from the set ofenterprise applications and customizations pushed to the same mobiledevice 502 of the same user during subsequent enrollment sessions.

In step 1005, after identifying one or more enterprise devices 502 toreceive an enterprise application customized in step 1003, a second setof customization parameters may be determined to further customize theenterprise application for the specific user and/or specific device thatwill receive the application. The second set of customization parametersdetermined in step 1005 may also depend on the specific enrollmentsession of the user and device, so that different enrollment sessions ofthe same device by the same user may result in different sets ofapplications and/or customizations of applications. Similar to thecustomization parameters discussed above in step 1002, the customizationparameters in step 1005 may include any combination of parameters tocustomize the functional behavior and/or the appearance of theapplication. For example, such parameters may include parameters tocustomize the look-and-feel of the application, such as a customapplication name, a friendly name, an application icon, one or more userinterface component specifications (e.g., window size and positioning,background color and themes, etc.), application-specific policies,service registrations, service URIs, and the like. The customizationparameters also may include locations of source code files or custombinaries, address table data, or other parameters used to customize thefunctionality of the application.

In step 1006, a second customization of the enterprise applicationcustomized in step 1003 may be performed, based on the second set ofcustomization parameters selected in step 1005. In some cases, thesecond customization process 1006 may be performed using the same orsimilar software tools and features as the first customization process1003. The customized application may be retrieved and be opened, forexample, by decompiling or decomposing the application into readableand/or editable code (if necessary) after which the application may bemodified based on the second set of customization parameters selected instep 1005. Like the first customization 1003, the second customization1006 may be performed at the enterprise store 540, at the client device502, or by a combination of components within an enterprise mobilitymanagement system, and may be performed using the various software toolsand processes described above in FIG. 9.

As discussed above in step 1003, the customization of a web applicationmay include configuring the functional and user interface features ofthe web-browser controls, creating a customized look-and-feel for theenterprise application, as well as configuring controls and securityfeatures of the internal application browser. The second customizationof web applications in step 1006, which may be user-specific,device-specific, and/or session-specific, may involve configuring someor all of the same features of the web applications. For example, afterdetermining various server endpoints for a web application based on theuser, device, and/or session, the second customization 1006 may includeconfiguring the web application's controls and security features basedon the determined server endpoints. For instance, scripting, applets,legacy browsing behaviors and other browsing features may be enabled ordisabled based on server endpoints determined for the application (whichmay be user-, device-, or session-specific). Additionally, a webapplication may be customized in step 1006 to incorporate clientcertificates linked to the user enterprise profile of the user that willreceive the application. Similar customizations may be performed in step1006 for non-web applications, such as hosted enterprise applications,after the appropriate server URLs for the specific users, devices,and/or sessions are determined. For example, various HDX/ICA clientoptions may be incorporated into the application bundle during thecustomization of step 1006, such as adding built-in authenticationcertificates into the application.

Thus, as illustrated in FIG. 10, two separate customization processesmay be performed on an enterprise application provided to user devicesin an enterprise system: a first customization of a template applicationbased on a first set of enterprise-specific customization parameters,discussed above in steps 1001-1003; and a second customization of thecustom enterprise application based on a second set of user-specific,device-specific, and/or enrollment session-specific customizationparameters, discussed above in steps 1004-1006. In some examples, thefirst set of customizations may correspond to enterprise-widecustomizations selected by an enterprise administrator or determined byenterprise policies. Such customizations may be applicable to an entireenterprise mobility management system and may be performed before makingthe application available to users. In contrast, the second set ofcustomizations may correspond to user-specific, device-specific, and/orenrollment session-specific customizations that are applied after anapplication has been selected by (or selected for) an enterprise userand just before providing the application to the user's mobile device.In some systems, the first customization may include enterprise-widecustomizations of an application that define the overall applicationappearance and look-and-feel chosen by the organization, along with thefunctional application features provided by the organization, whereasthe second customization may include user-, device-, or session-specificcustomizations such as embedding the appropriate server URLs for theuser into the application, enabling and disabling certain applicationfeatures based on the user's functional requirements or level ofpermissions, or changing the display and input/output features of theapplication based on the capabilities of the device that will receivethe application. In such examples, the sets of customization parametersmay be entirely different for the first customization and the secondcustomization. However, in other examples, the first and second set ofcustomization parameters may overlap, such that the first customizationmay set and configure certain aspects of the application for generalenterprise use, which then may be changed or overwritten during thesecond customization based on the specific user, device, or enrollmentsession during which the application will be received.

In step 1007, the enterprise application that was customized in step1003, and customized again in step 1006, may be provided to the mobiledevices of one or more enterprise users. As discussed above, thecustomized enterprise application may be published to an enterpriseapplication store 540, where it may be selected by a user and thencustomized again for the user or device, after which it may be providedto the user's mobile device 502. In other cases, the customizedapplication may be selected by an enterprise administrator or enterprisepolicy to be distributed to one or more specific users or devices(and/or during specific enrollment sessions), after which the customizedapplication may be further customized for each selected user, device,and/or session and then automatically transmitted to the appropriatemobile devices 502 during or after the enrollment process. Similartechniques may be used for providing customized updates (e.g.,enterprise-specific, user-specific, device-specific, and/orsession-specific customizations) of existing enterprise applicationsresiding the mobile devices within the enterprise mobility managementsystem.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are described asexample implementations of the following claims. Aspects of thedisclosure have been described in terms of illustrative embodimentsthereof. Numerous other embodiments, modifications, and variationswithin the scope and spirit of the appended claims will occur to personsof ordinary skill in the art from a review of this disclosure. Forexample, one of ordinary skill in the art will appreciate that the stepsdescribed and/or illustrated herein may be performed in other than therecited order, and that one or more steps illustrated may be optional inaccordance with aspects of the disclosure. Modifications may be made,particularly in light of the foregoing teachings. For example, each ofthe elements of the aforementioned embodiments may be utilized alone orin combination or sub-combination with elements of the otherembodiments. It will also be appreciated and understood thatmodifications may be made without departing from the spirit and scope ofthe aspects described herein.

1. A computer-implemented method comprising: generating data based on anidentifier in response to a request from a mobile device to access aremote resource, the data configured to enable access to the remoteresource and being different from data used by other mobile devices toaccess the same remote resource, and the identifier being indicative ofone of the mobile device or the remote resource; and providing anapplication to the mobile device, the application including thegenerated data to enable the mobile device to access to the remoteresource without retry of credentials to authenticate a user of themobile device.
 2. The computer-implemented method of claim 1, whereinthe request comprises a request to remotely manage the mobile device. 3.The computer-implemented method of claim 1, wherein the generated datacomprises a set of application parameters.
 4. The computer-implementedmethod of claim 1, wherein the generated data comprises one or moreenterprise uniform resource locators (URLs) of the remote resource. 5.The computer-implemented method of claim 1, wherein the generated datapermits the application to automatically access the remote resourceduring a first-time use of the application.
 6. The computer-implementedmethod of claim 1, wherein the generated data comprises user interfaceand user experience preferences from the other mobile devices.
 7. Thecomputer-implemented method of claim 1, wherein providing theapplication comprises sending the application to the mobile device usinga protocol.
 8. The computer-implemented method of claim 1, wherein theapplication comprises a line-of-business (LOB) application.
 9. Thecomputer-implemented method of claim 1, wherein the generated datacomprises a session cookie and generating the data comprises: generatingthe session cookie based on a plurality of identifiers, one of whichbeing the identifier of the mobile device, the session cookie beingunique to a session of the mobile device.
 10. The computer-implementedmethod of claim 1, wherein the generated data comprises a session cookieand the method further comprises: after providing the application to themobile device, retrieving an expiration time from the session cookie;determining that the session cookie is valid based on the expirationtime; and permitting the application to access the remote resource viaSingle-Sign-On (SSO).
 11. A computer-implemented method comprising:generating data based on an identifier in response to a request from amobile device to access a remote resource, the data configured to enableaccess to the remote resource and being different from data used byother mobile devices to access the same remote resource, and theidentifier being indicative of one of the mobile device or the remoteresource; determining a set of application parameters associate with atleast one of the other mobile devices; and providing an application tothe mobile device, the application including the generated data and theset of application parameters, to modify access by the mobile device tothe remote resource based on the set of application parameters.
 12. Thecomputer-implemented method of claim 11, wherein the request comprises arequest to remotely manage the mobile device.
 13. Thecomputer-implemented method of claim 11, wherein the generated datacomprises one or more uniform resource locators (URLs) of the remoteresource.
 14. The computer-implemented method of claim 11, wherein thegenerated data permits the application to automatically access theremote resource during a first-time use of the application without retryof credentials to authenticate a user of the mobile device.
 15. Thecomputer-implemented method of claim
 11. wherein providing theapplication comprises sending the application to the mobile device usinga protocol.
 16. A server device, comprising: at least one processor; acommunication interface; memory storing instructions that, when executedby the at least one processor, cause the server device to: generate databased on an identifier in response to a request from a mobile device toaccess a remote resource, the data configured to enable access to theremote resource and being different from data used by other mobiledevices to access the same remote resource, and the identifier beingindicative of one of the mobile device or the remote resource; andprovide an application to the mobile device, the application includingthe generated data to enable the mobile device to access to the remoteresource without retry of credentials to authenticate a user of themobile device.
 17. The server device of claim 16, wherein the requestcomprises a request to remotely manage the mobile device.
 18. The serverdevice of claim 16, wherein the data permits the application toautomatically access the remote resource during a first-time use of theapplication.
 19. The server device of claim 16, wherein the datacomprises one or more enterprise uniform resource locators (URLs) of theremote resource.
 20. The server device of claim 16, wherein the datacomprises a session cookie, and wherein the memory stores additionalinstructions that, when executed by the at least one processor, causethe server device to: generate the session cookie based on a pluralityof identifiers, one of which being the identifier of the mobile device,the session cookie being unique to a session of the mobile device.